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(54) AuthentHicatlon of data In a digital ti^nsmisslon system 



(57) A method of authentification of data sent In a 
digital transmission characterised by the organisation 
and authentification of the data prior to transmission into 
a hierarchy of at least one root directory module 75, 
sutxJirectory module 76 and file module 77. data in a file 
77 being acted upon by an autherrtification algorithm 
and an associated file authentification value 82 stored in 
the referring subdirectory module 77, this file authentifi- 
cation value 82 being in turn acted upon by an authenti- 



fication algorithm and an associated subdirectory 
authentification value 79 stored in the referring root 
directory module. 

Other aspects of the invention relate to the authen- 
tification of a second root directory 78 by generation of 
a second authentification value 83 and the authentifica- 
tion of data before encapsulation in a transport stream. 
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SL- ^'T"^ '^^^ «o a method of 

s^em " « '^'■S'*^ transmission 

l[0002J Broadcast transmission of digital data is well- 
known ,n the field of pay TV systems. Jherrscra J^^i 
aud.<Msual .nfom«tion is sent usually by SeZ t 

SSmS descrambling the 

traremrtted program for subsequent viewing Territrial 
digital broadcast systems are also known ReS^Sfv? 

2i.^?f ° °' ^ a^i^'sual data, such 
aeccxier or a to a connected PC 

Stion^ d^?"r' -"'f ^"^ transmission of 

application data lies in the need to verify the integrity 
and ongin of any such date. Since date o/this 
be ised to reconfigure the decoder, as well as^ 

ZZLZT^ ''^^^^'^^^^^^^ 
partial lhat the received data is both complete and 

^entrfied as originating from a known souS (ih^ 

.*c?m^t?ir "^"^^ *° downloadhg Of 

dS be^lT^ ^= risk that the 

d««ler becomes open to attacks by thirt parties or the 

WOM] Previous attempts to authentcate such data 
have concentrated on the verification of thToaSS 
stream of date received directly by the deJLS^ 
sample, through the signature and' enij^^^^tS 

rooos] The problem with such known systems lies in 

«-^n,sal,on structures. In particular, the useof a siS e 
^r^ojv teble containing a complete Itet of h^h vaS 
?««^.^°°^''^*^«'^^"=th^«"ch systems «^ 

bers of tables. The system is equally ill adaoted To 
pem,rt authentification of software praviS^ S a 
number of broadcast operators, since a Tgt MPBG 

tono the date in the MPEG packets is carried o^t the 
«>mp ession stege. under the control of a sole op J^tor 
r0O06] AccordingtoafirstaspectofthepreserJinven- 

S renHn'.r.".!' '"^'^ " authentificatiW 
oate sent in a digital transmission characterised bv tho 
organisation and authentification of the Sa pSor to 
transm^on info a hierarchy of at least on el^JXe^ 
n a'f^lTJ^^- "^"'^ moTe Sate 

Loo Jh^Si^ "P"" ^ authentificatron 

algorithm and an associated file authentification value 



f^^- ^ ^""9 subdirectory module, this file 
Th^hT" ^^"^ ««ed upon by an 

authentrfication algorithm and an assodated subdfr^ 

s 2;i^:~-"-°-'-e;?e:r:o^- 

ic !^.I''*^?''^«°"^'9°^"^'"ateachstepSrhS 
ture. As a file authentification value in a subdirectory is 
vZ'iT^"^ ^ ''''' ^ « co^esSg 

,5 !,7h^« ^ '«^«hout changing the 

SJS^ "p"" r*"? " '^'S'^-^ (and vce'v^Sar 
S aSl^"'"1'- «"t^«"«'«tton of the file date is 

« tTn t^' '^"^ ^^"e being stored 
L^' ^"'f'«"*»'^ion of a subdirectory may 
authentification value (and other date, if desired) *,! 

°*«^«"*°d""ente may be envisaged for 
^mple. where file date is encrypted in accordance 
J«th anejKryption algorithm and the encryptiS, teyTor 
Slue'Sn r^;^"^ "^"^ aXntifSn 
oe encrypted and the encrypting key stored in the root 

We. this embodiment is rather more complicated to out 
Place due to the increased comple^ToTtS^opeS^ 

^ imm""T''^ encryption l^valu^'"^ 

2?1 ^ . .[ °' hashing algorithm to 

carry out the authentification of each module a 
parftcularly simple and rapid check oTSe irSS^o^ 
each module to be carried out In one en^SS a 

non may oe used. However, this would not enable a 
^'"^^ ^ — se affe^ the 

45 the hashing algorithm corresponds 

« to "ryptographically secure algorithm that gene^^a 

Surtable hashing algorithms that may be used for Ts 

50 (Sh4. ^ " "'^ Ci"m 

Sity'tS'''°"''^: ^"t^'^'^'^on Of file date for 

algoSrn to " "^7'^ ''^^ ^'y'"^ « ''^hing 
algonttm to an accumulation of date from a plurality of 
files to generate a single hash value Eouallv auSfT 
« ^t^no'anumberofsubdirectori^mrbfc;^^^^^ 

nes (and other date, if desired) to generate a single 
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hash vatua 

[0013] The use of a cumulative hashing prcx:ess to 
cover a plurality of data modules (files, subdirectories 
etc.) at a lower layer further simplifies the system in 
comparison, for example, with systems which store Dst 
of individual hash values for each module. This again 
enables the system to reduce the calculation steps 
needed at each level and reduces the size of authentrfi- 
cation data stored in an upper layer. 
[0014] In the case of the embodiments using a hash- 
ing algorithm to authenticate each layer, the system will 
be "open", that is, all the hash values will be readable up 
to the root directory. Since hashing algorithms are pub- 
lically available, a third party could theoretically change 
stored data e.g. at a file level without detection if the cor- 
responding hash values at subdirectory and root direc- 
tory le^/el were also changed at the same time. 
[001 5] In order to avoid this, at least some of the data 
stored in the root directory is acted upon by a secret key 
of an encryption algorithm and the resulting encrypted 
value stored in the root directory. Preferably, the 
encrypted value corresponds to a digital signature. Suit- 
able privateyjDutrfic key algorithms for this purpose 
include, for exarrple, the RSA algorithm. 
[001 6] Advantageously, at least one or more subdirec- 
tory authentification values are encrypted by a secret 
key to generate a signature stored in the root directory. 
It is nevertheless possible to envisage data in the root 
directory other than the sutxdirectory authentification 
values being signed in order to "dose" the system. 
[0017] In an alternative to the generation of a signa- 
ture, the whole or part of the root directory may simply 
be encrypted or scrambled, the receiver possessing an 
equivalent key to decrypt the encrypted root directory 
data. In this case, a symmetric key algorithm such as 
DES may be used. 

[0018] As will be understood, whilst the authentifica- 
tion process has been described atxjve with reference 
to two hierarchical levels, similar authentification steps 
may be carried out ad infinitum for further refen-ed files, 
subdirectories, root directories, etc. 
[001 9] Similariy. whilst the structure has been defined 
as root directory/sutibirectory/file for the sake of clarity 
of language, no particular characteristic of each module 
in a layer is assumed, other than tiie referral to a lower 
layer module by two upper layer modules. As will be 
understood, the data structure may just as equally be 
root directory/sukxJirectory/second root directory or any 
other combination. 

[0020] The following described embodiments focus on 
a nxxjule in a lower layer, i.e. referred to by a directory 
or subdirectory. As will become clear, although referred 
to from an upper layer, this module may nevertheless 
itself be a directory module, subdirectory module etc. 
[0021] in one embodiment one refened module 
includes an encrypted value generated by a seaet key. 
an authentification value for this module being calcu- 
lated based on the results of an authentification algori- 



thm on the encrypted value and stored in the referring 
module. In particular, as with the equivalent root direc- 
tory embodiment described atx)ve. a referred module 
may be signed, the authentification value for that mod- 
5 ule being calculated as the result of a hashing function 
on that signature. 

[0022] This embodiment is particulariy adapted to the 
situation in which the referred module is a root directory 
for a furttier set of data, e.g. of a different origin and 

10 where the referred root modules also includes a signa- 
ture. In this case, a first operator can assemble and sign 
data up to the level of the root directory. 
[0023] Thereafter, a second operator can refer to tiiis 
data without knowing the encryption key, any link simply 

75 being authentified in the referring module by the hash 
value of the signature in the referred root directory 
Authentification of both sets of data will of course only 
be possible to a receiver possessing the necessary 
keys to verify the signatures in both root directories. 

20 [0024] As described above, the present invention may 
be applied to any set of multiple hierarchy data mod- 
ules. It may even be applied to the organisation packets 
in a t^nsport stream, if multiple levels of root cBrectory. 
subdirectory, file etc. can be provided. However, tiiis 

25 invention is particularly applicable to tiie case in which 
tiie data modules con-espond to a set of data files, tiie 
data files t>eing thereafter encapsulated in data packets 
to form a transport stream. 

[0025] Unlike authentification at tiie packet level, tiiis 

30 embodiment enables complete independence between 
the assembly of authentified data and its encapsulation 
in a transport stream and, again, facilitates tiie supply of 
software from different sources in the transport stream 
controlled by a single broadcast operator. 

35 [0026] In particular, tiie data modules may preferably 
correspond to data objects formatted according to tiie 
DSMCC standard. Furtherrnore, the data files are pref- 
erably encapsulated in data packets conforming to tiie 
MPEG standard. 

40 [0027] According to a second aspect of the present 
invention there is provided a method of authentification 
of a first and second set of linked data modules sent in 
a digital transmission, characterised in that at least one 
of the first set of modules includes a signature gener- 

45 ated by a secret key acting on tiiat first module, at least 
this signature value being authentified by an authentifi- 
cation algoritiim and the authentification value being 
stored in a module in the second set of modules that 
refers to tiiat first module. 

so [0028] According to a tiiird aspect of the present 
invention there is provided a method of authentification 
of data sent in a digital transmission, characterised in 
that data is organised in a series of files, autiientification 
being carried out between files and prior to encapsula- 

55 tion of the files in a series of packets in a t-ansport 
stream. 

[0029] Any or all of the features of the first aspect of 
the invention and its preferred embodiments may of 



"S^"" aspect 
'"'Kin, applleato, SSf to ^ T""' 

S- s^r 

system the invention ^'^^►aacasl digital television 
r0033] The term Veceiver/decodPr'' nr "H..^ i n 

[0034] TTie term MPEG refers tn tho ho*. 

[0036] There will now t>e dpsrr.>ww k 
pie only, a preferred emb^m^,*?;!'::!^ °' "^"^ 
reference to me anac^Stirin wS"''^°" ^'^ 
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Figure 2 shows the structure of a decoder of 
system of Figure 1 ; aecoaer of the 

SoV:^e?:fSotire^°'"--«- 

^^a^ffles and the eventually produced MPEG 



Figure 6 showire the client «:MT/or . 
R»u.e 7 shows me aulhe«tei <i,eaofy. si»dl,«: 



9/ision system 2 ^ conventional digital tel- 

by the end user T . ^ ^'^ °r rented 

■tsiiiea oy tne end user and connertari 
users television set id tiT *o «he end 

decodes the c^prii m^^ receiver/decoder 13 

« -„3ig„a,fort^reSons^'?r''"''"*°^*^^- ■ 
Se^L a';^";*'^'^^ ^^""^"^ transmission of 
broadest ^etrTn"^' '""^ ♦^^«^"al 

« ^^^^^^^^ 
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ital data in the form, for example, of DSM-CC format 
software files and messages, will be compressed and 
packetised into the MPEG format by the confpressor 3. 
The downloading of software modules will be described 
in greater detail below. 5 
[0041 ] A conditional access system 1 5 is connected to 
the multiplexer 4 and the receiver/decoder 13. and is 
located partly in the broadcast centre and partly in the 
decoder. It enables the end user to access digital televi- 
sion broadcasts from one or more broadcast suppliers. io 
A smartcard. capable of deciphering messages relating 
to commercial offers (that is. one or several television 
programmes sold by the broadcast supplier), can be 
inserted into the receiver/decoder 13. Using the 
decoder 13 and smartcard. the end user may purchase is 
commercial offers In either a sut)Scription mode or a 
pay-per-view mode. In practice, the decoder may be 
configured to handle multiple access control systems, 
e.g. of the Simulcrypt or Multicrypt design. 
[0042] As mentioned above, programmes transmitted 20 
by the system are scrambled at the multiplexer 4. the 
conditions and encryption keys applied to a given trans- 
mission being determined by the access control system 
15 Transmission of scrambled data in this way is well 
known in the field of pay TV systems. Typically, scram- 25 
Wed data is transmitted together with a control word for 
descramWing of the data, the control word itself being 
encrypted by a so-called exploitation key and transmit- 
ted in encrypted form. 

[0043] The scrambled data and encrypted control 30 
word are then received by the decoder 13 having 
access to an equivalent of the exploitation key stored on 
a smart card inserted in the decoder to deaypt the 
encrypted control word and thereafter descramble the 
transmitted data. A paid-up subscriber will receive, for 3S 
example, in a broadcast monthly ECM (Entitlemerrt 
Control Message) the exploitation key necessary to 
decrypt the encrypted control word so as to permit view- 
ing of the transmission. In addition to their use in 
decrypting audiovisual television programs, similar 40 
exploitation keys may be generated and transmitted tor 
use in the verification of other data such as software 
modules as will be described t>elow. 
[0044] An interactive system 16, also connected to the 
multiplexer 4 and the receiver/decoder 13 and again 45 
located partly in the broadcast centre and partly in the 
decoder, enables the end user to interact with various 
applications via a modem back channel 17. The modem 
back channel may also be used for communications 
used in the conditional access system 1 5. An interactive so 
system nr^y be used, for example, to enable the viewer 
to communicate immediately with the transmission cen- 
tre to demarKi authorisation to watch a particular event, 
download an application etc. 

[0045] Referring to Figure 2. the physical elements of ss 
the receiver/decoder 13 or set-top box adapted to be 
used in the present invention will now be briefly 
described. The elements shown in this figure will be 



descrtoed in terms of functional blocks. 
[0046] The decoder 13 comprises a central processor 
20 including associated memory elements and adapted 
to receive input data from a serial interface 21 , a parallel 
interface 22. and a modern 23 (connected to the 
modem back channel 1 7 of Fig 1 ). ^ 
[0047] The decoder is additionally adapted to receive 
inputs from an infra-red remote control 25 via a control 
unit 26 and from switch contacts 24 on the front panel of 
the decoder. The decoder also possesses two smart- 
card readers 27. 28 adapted to read bank or subscrip- 
tion smartcards 29, 30 respectively. Input may also be 
received via an infra-red keyboard (not shown). The 
subscription smartcard reader 28 engages with an 
inserted subscription card 30 and with a conditional 
access unit 29 to supply the necessary control word to 
a demultiplexer/descrambier 30 to enable the encrypted 
broadcast signal to be descrambled. The decoder also 
includes a conventional tuner 31 and demodulator 32 to 
receive and demodulate the satellite transmission 
before being filtered and demultiplexed by the unit 30. 
[0048] Processing of data v«thin the decoder is gener- 
ally handled by the central processor 20. The software 
architecture of the central processor corresponds to a 
virtual machine interacting with a lower level operating 
system implemented in the hardware components of 
the decoder. 

[0049] There will now be described, with reference to 
Figures 3 and 4. the packet structure of data within the 
broadcast MPEG transport stream sent from the trans- 
mitter to the decoder. As will be appreciated, whilst the 
description will focus on the tabulation format used in 
the MPEG standard, the same principles apply equally 
to other packetised data stream formats. 
[0050] Referring in particular to Figure 3. an MPEG 
bitstream includes a programme access table ("PAT") 
40 having a packet identification ("PID") of 0. The PAT 
contains references to the PIDs of the programme map 
tables ("PMTs") 41 of a number of programmes. Each 
PMT contains a reference to the PIDs of the streams of 
the audio MPEG tables 42 and video MPEG tables 43 
for that programme. A packet having a PID of zero, that 
is tiie programme access table 40. provides the entry 
point for all MPEG access. 

[0051 ] In order to download applications and data for 
tiiem, two new stream types are defined, and the rele- 
vant PMT also contains references to the PIDs of the 
streams of application MPEG tatJes 44 (or sections of 
them) and data MPEG tables 45 (or sections of them). 
In point of fact, whilst it may be convenient in some 
cases to d^ine separate stream types for executable 
application software and data for procesang by such 
software, tiiis is not essential. In other realisations, data 
and executable code may be assembled in a single 
stream accessed via the PMT as described. 
[0052] Refening to Figure 4. in order to download, for 
example, an application within a stream 44, the applica- 
tion 46 is divided into modules 47. each formed by an 
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^ I °' «"n3rise a single 

secton Whilst others may be made up by a plurality of 

sectons 48. A typical section 48 has a LSer. 
includes a one^yte table identification (TID") 50 the 
secton number 51 of that section in the table, the total 5 
number 52 of sections in that table and a two-byte TID 
^tension reference 53. Each section also includes a 
date part 54 and a CRC 55. For a particular teble 47. all 
of the sections 48 making up that table 47 have the 

same TID 50 and the same TID extension 53. For a par- 
t«:ular application 46. all of the tebles 47 making up tt^t 
applicaton 46 have the same TID 50. but different 
respective TID extensions. "-nereni 

[0053] For each application 46. a single MPEG table 

lie "^''^"^ ^- "^^ *^««^y table 56 ' ,5 

has in Its header, the same TID as the other tebles 47 
making up the application. However, the directory table 
^s a predetermined TID extension of zero for identifi- 
SSlSTw^.^"" *° factonly a single table is 
^^1°" 'nformation in the directory. All of the so 
other tebles 47 will normally have non-zero TID exten- 

tions 48. The header of the directory teWe also includes 
fn^.°" o!!."*^ °^ *^ application to be downloaded 
2^ "f*":'"9'«cktoRgure3.thePAT40.PMTs as 
41 and application and date stream components 44 45 

ZL^tl^"l ^"^^^ Each application which is 
transmitted has a respective predetermined TID To 
download an application, the MPEG table having the 

^W^^ receiver/decoder. TWs is the directory 
t Jil^K application. The date in the direc- 

tory IS then processed by the decoder to determine the 
TID extensions of the tables making up the required 
Stm .TZT'r.^''' required'teSe having thl ss 
detTJI^? the directory teble and a TID extension 
fn,^jr^ ''''^o^ be downloaded. 

"^^^^ ^"^"9«* to <*e<* the directory 
teble for any updating of it. This may be done by down- 
loading the directory table again periodically, for exam- 40 
pie every 30 seconds, or one or five minutes, and 
rampanng the version number of the previously down- 
loaded directory teble. If the freshly downloaded version 

ated wrth the previous directory teble are deleted, and ^ 
^^^fated with the new veision downloaded 

and assembled. 

S 1!"^" ^a^"^"^ arrangement, the incoming blt- 
?D .!! """^ ^ "^"^ corresponding to the 
for the TID of the application, a TID extension of zero 

nu^tffJ^T" 9^^*^^ the version 

number of the currently downloaded directory Accort- 

fcS anJ^ once detected the directory is down- 55 

and the application is updated, as described 
^e. If an application is to be terminated, an empty 
directory with the next version number is transmittS^ 



but wrthout any modules listed in the directory. In 
response to receipt of such an empty directory "the 
decoder 2020 is programmed to delete the application 

^^'^ ^"^ «"^"*e^ P^-^nis to 
«p^ment applications in the decoder may be intro- 

di^edNnaanyofthe parts ofthe decoder, in particular in 
jLrtS't '^"''^"^ ^^""e "nk as 

eta_Suchsoftware may comprise high level applications 
used to implement interactive applications within the 
decoder such as net browsers, quiz applications pro- 

Sch/nii 1' ^^'^ ''^ downloaded 
to cha^e the working configuration of the decoder soft- 
J^^ tor sample by means of "patches" or the like. 
P»058] Applications may also be downloaded via the 

decoder. In such a case, the decoder acts as a commu! 
nica^ion router for the software, which is eventuaOy mn 

^h""!."!!!!^ •"^'""'ontothisroutingLr 
ton the decoder may also function to convert the 
MPEG packetised data before routing to the PC into 
computer file software organised, for example accord- 
ing to the DSMCC protocol (see below) 

S * 'neasures implemented to verify the 

completeness and origin of application data have 
focussed on verifying the tables in the MPEG packet 
stream. In particular, in conventional systems, a hash 
ftincbon IS applied to each of the individual sections 48 
pnor to transmission and tfie resulting check value or 
agitetare for each section stored in a list in tiie directory 
tette^ serjt to the decoder Comparing the hash value 
^equentiy calculated by the decoder with the check 
^ue *,red in the directory for a received section ena- 

'"^f^;"^ '^^^^ to be verified. 

I ! . *^'^«^°^y ^ "«y equally be 

TJ^ to a hashing pixjcess to general a fu^^he' 
*eck value or signature for the directory table 40 Fur- 
themiore. this checking value can be encrypted by a pri- 
vate key and stored in the directory table. Only thL 
decoders possessing a corresponding public key mav 
authentificate the signature. ^ 
10061 ] In contrast to such conventional systems the 
present embodiment relates to a means tor securing 
aol verifying application date organised in a multiple 
hieiarciv of date files or objects at the level of flie appli- 
cation. This will be understood more dearly from |W^ 
5 which shows the relationship between date organfeed 
set of DSMCC U-U date files 60. in an aieS 

S?E?t^es 47."" " ^ ^ 

E^^l l""' *° ^'^nsmission. the date files are assem- 
bvln mpS ^- thereafter, packetised 

by an MPEG compressor into MPEG tebles or modules 

M^o*'^ « header 49 specific 

to the MPEG packet stream and including table ID ver- 
sion number etc. As will be appreciated, there may be 
^Jl"^ ^^S^^ised in the date 

fries 61 and the eventual MPEG tables 47. After recep- 
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tion and filtering by the decoder, the packet headers 49 
are discarded and the application 46 reconstituted from 
the payload of the tabies 47. 

[0063] The DSMCC format for data files is a standard 
adapted in particular for use in multimedia networks and 
which defines a series of message formats and session 
commands for communication betwe©i a client user 70, 
a server user 71 and network resource manager 72. 
See Figure 6. The network resource manager 72 may 
be considered as logical entity acting to manage the 
attribution of resources within a network. Although ini- 
tially conceived tor use in the context of l>idirectional 
network communication, recent implementations of the 
DSM-CC standard have focused on its use for unidirec- 
tional broadcast purposes. 

[0064] Communication between a client and a server 
is set up by a series of sessions, a first series of mes- 
sages being exchanged between a user (client 70 or 
server 71) and the network manager 72 in order to con- 
figure the client and/or server for communication. Such 
messages are formatted according to the so-called 
DSMCC U-N (user to network) protocol. A subset of this 
protocol has been defined in particular for broadcast 
downloading of data. 

[0065] Once a communication link has been estab- 
lished, messages are subsequently exchanged 
between client 70 and server 71 according to the 
DSMCC U-U (user to user protocol). A sequence of 
messages of this kind correspond to the data files 60 of 
Figure 5. In the case of DSMCC U-U messages, data is 
organised in a series of messages 61 grouped accord- 
ing to the BlOP or Broadcast InterOrb Protocol. 
. [0066] Each message or object 61 comprises a 
header 62, a sub-header 63 and a payload 64 contain- 
ing the data itself. In accordance with the BlOP protocol, 
the header 62 contains, inter alia, an indication of the 
type of message and the BlOP version whilst the sub- 
header indicates the type ot object and other informa- 
tion to be defined by the system architect 
[0067] Data objects 64 within the payload of DSMCC 
U-U files may generally be defined as one of three 
types; directory objects, file objects and stream objects. 
Directory objects deline root directories or sutxJirecto- 
ries used to reference a series of associated file objects 
containing the actual application data. 
[0068] Stream objects may be used to enable a tem- 
poral relationship to be established between data con- 
tained in the data files and the MPEG packet stream 
itself. This may be used, for example, in the case of 
interactive applications contained in the data files and 
designed to be synchronised with the elementary video 
or audio streams received and processed by the 
decoder. As mentioned alxjve. there may othenwise be 
no direct correlation between the MPEG packetised 
data and the data files 

[0069] Unlike the MPEG tables, where a single direc- 
tory references a set of tables with only a single level of 
hierarchy, the data files 60 may be organised in a rather 



more complex hierarchical manner. As with files stored 
in a PC or server, a main or root directory may refer to 
one or more subdirectories which refer in turn to a sec- 
ond level of data files. Reference may even be made to 
5 a second root directory associated with another set of 
application data. 

[0070] Referring to Figure 7, an example of file struc- 
ture for a set of data files is shown. A root directory DIR 
AO indicated at 75 references a group of subdrectories 

10 A1 to A4 indicated at 76. Each sutxJirectory 76 refer- 
ences one or more sets of associated object files 77. 
For the sake of clarity only a single group of object files 
F1. F2 etc. associated with the subdirectory A4 is 
shown. In practice a numt>er of groups of object files 

15 may be referenced by each of the subdirectories A1 to 
A4. 

[0071 1 Within each directory and subdirectory a set of 
authentrfication steps is introduced for the files linked to 
that directory. Referring to the root directory 75, the sub- 
20 header 63 comprises a hash value obtained by applying 
a hash algorithm to some or all of the data stored in the 
subdirectory files A1 to A4 indicated 76. The hashing 
algorithm used nr^y be of any known type such as, for 
example, the Message Digest algorithm MD5. 
25 [0072i In one realisation, the algorithm may be appFied 
to each associated file or subdirectory individually and a 
list of the hash values for each subdirectory 76 stored in 
the root directory 75 prior to transmission. However, 
whilst such a solution enables an increased degree of 
30 checking resolution in terms of verifying each subdirec- 
tory, this solution may be rather inefficient in terms of 
the processing time necessary for the decoder to calcu- 
late the corresponding signatures. 
[0073] Accordingly, the subheader 63 of the directory 
35 79 preferably comprises a cumulative hash value 79, 
calculated by applying the MD5 hashing algorithm to the 
combined sdDheader and payload sections 63, 64 of the 
subdirectories 76, that is, without the header 62. In par- 
ticular, the hash values 82 contained within the subdi- 
40 rectories 76 and referring to the layer of file objects 77 
are included in this hashing calculation. 
[0074] In the case of the subdirectory A4 shown in 
Figure 7. this subdirectory itself refers to a set of object 
files F1-Fn indicated at 77. In this case, a cumulative 
45 hash value 82 is gene-ated for the combined contents of 
the object files 77. This value is included in the hashing 
process giving rise to the hash value 79. It is therefore 
not possible to change any of the object files 77 without 
changing the hash value 82 of the subdirectory 76, 
so which in turn will change the hash value 79 of the direc- 
tory 75. 

[0075] In the present case, a combined hash value is 
calculated for all of the subdirectories A1 -A4 referenced 
in the directory. This hash value is stored together with 
55 an identifier of the group of subdirectories from which 
the data has been taken. In other embodiments, a 
series of combined or individual hash values and cone- 
sponding identifiers may be stored in the subheader of 
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the directory. 

10076] For example, a second set of subdirectories 
^ «^ated with the root directory but^S to a 
drffererrt set of data or executable code m^y all, be 

Sr"^ ^ '^"""'^^^^ hash™L Sc^ 
Zff S T ^^Wi^ectories calculated and stored in 

tt fubreSdVS^r --"^ ^ 

Eoes^rofcrer^rr^oLi^^^^ 

"xJeed. any other file) from also referring ,o nS^vS^ 

t^i^ "k'^"''"^ ^^'^ absence (S^IWa- 

tion Of such a file will need to be taken intoaS,Zf fn 

m^V^ ^y^- *° «'^«"f <=ate stream objects 
[0078] The use of a hashing function in this casenri 

e^r.!f Ihe downloaded data files. In the case, for 
example, of a fault or break in the transmission the 
operabon of a cumulative hashing algorithm on the 
re^e-veddependemfileswillnotgivetheLn^e^^^^^^^^ 

Z^^ 'T the root So^ 

The decoder w.ll then be alerted to the presence T^'. 

ste J^T^a^ T"""^ "cScS 

srgiTarrjf ^'-p'^ 

S^Sri, '"'■9"^^ 7' root directory 75 

•dentify to the decoder the public kev to be .^IT ^ 

t« In 1 ^^"^^^^ "^"9 the private key of the opera 

Inn l*^^^' 81 is generaSbv 

S?Z!'?'^"'^^>'^«"''y'h«oP««orto?cS^o? 
all of the data within the directory 75 preferably inci!.ri 

Si J' '^^^ ^''^ Signature 

[0083] In this example, the data in the directon/ 7^ 
unencrypted and the private key is si^l^iruSSto pr.;! 
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aereaecJ at the verification stage Since h^Ji 

^ue te generally unique to a given sJ^darifwotS 
" ^^^[^ "-^ be possible to Change the coSo aTy o^ 
dependent hashed files without changing fte^ diarac 

r:f^^2rry^----^--r«ing^^^^^^ 

^ Siles^'rl?''"''*"^ -"'^«*>"es 76 and 

« EenIS^rT-'''^^'^'"9°"*'^«PP«««°ntobe 
fT • '^^'■^"'^e may equally be made to a set of 

dma f,^ associated with a second operator Tin tife 

a^A £!'^r?B'o;'^*^^y^''^AOfo^theoper- 
E^^ J^' ^ «*'recto^y indicated at 78 

•ncludes one or more cumulative hash code Sues If 
associated with its assodated subd^oS^ 

operatorprivatek^. ^ corresponding 

[0088] A hash value for this directory is calculated 

hl'^e Of thf. "ir^ ^'^"^^-^^^^^^^^ 
neader of the directory and the pavload data «f 

" Je^-'t:^ ™^ ^or^^n 
tt^e subdirectory A4 thereby enabling a verificatori o^ 
J^-megnty of the data in the directed table rbe ca^^ 

^ o-flu """"^ calculation of the hash 
>«lue 83. the irtegrity of the rest Of the data files ref^S 

none I'^T^ w assumed XI 

none of these dependent files may be changed wiSS 
changing the hash value 84 and more h^S^f* 
ss signature value as <5in^« 4i, • 'mportanlly. the 
calr^»wt w signature value 86 is only 

caioj^able by a person possessing the private ooerator 
toy the integrity of all files refened to by '»,^ireSi ^ 
•nay be assumed, assuming corresponding has^uS 
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are calculated for further deperxlent subdirectories and 
object files. 

[0090] In this way, application data relating to execut- 
able programs or the like generated by a second opera- 
tor may be interlinked with applications associated with s 
a first operator in a secure and reliable manner. 
[0091] As will be appreciated, a number of variations _ 
may be possible, notably to reduce the amount of data 
hashed or signed at each stage. In particular, in the 
case of a signature or hash value in a directory or sub- 
directory used to verify a lower level data file, the direc- 
tory signature or hash value may be generated using 
only the lower level hash value and no other data. 
[0092] For example, the combined hash value 79 in 
the AO directory 75 xr\ay be generated using the com- 
bined hash values 82. 83 of each of the A1 -A4 subdirec- 
tories indicated at 76. Since tiiese values are just as 
unique as the data in the payloads of the sulxlirectory, 
the combined hash value 79 will still be unique to the . 
subdirectories in question. Furthermore, the integrity of 
the lower level of object and directory files 77, 78 may 
still be assumed since tiie hash values 82 are still used 
in the calculation. 

[0093] Equally, tiie hash value 82 calculated to verify 
the BO directory indicated at 78 may be calculated sim- 
ply using the signature value 86. Since this is depend- 
ent on and uniquely associated with the hash values 84, 
which hash values are in turn dependent on the next 
level of files, the integrity of the whole of tiie sets of data 
files referred to by tine directory 78 may still be 
assumed. 

Claims 

1 . A method of authentrf ication of data sent in a digital 
trarsmission characterised by the organisation and 
autiientif ication of the data prior to transmission into 
a hierarchy of at least one root directory module, 
subdirectory module and file module, data in a file 
being acted upon by an authentrfication algorithm 
and an associated file authentification value stored 
in the referring subdirectory module, this file 
authentification Value being in turn acted upon by 
an authentification algorithm and an associated 
subdirectory authentification value stored in the 
referring root directory module. 

2. A metinod as claimed in claim 1 , in which authentifi- 
cation of the file data is carried out by applying a 
hashing algorithm to some or all of the file data, the 
resulting hash value being stored as tiiefile authen- 
tification value in the refen-ing stdxJi rectory. 

3. A metiiod as claimed in daim 2. in which the hash- 
ing algorithm corresponds to a cryptographically 
secure algorithm that generates a substantially 
unique hash value from a given set of data. 
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4. A method as claimed in any preceding claim, in 
which authentification of file data for a plurality of 
files is carried out by applying a hashing algorithm 
to an accumulation of data from a plurality of files to 
generate a single hash value. 

5. A metiiod as claimed in any preceding claim, in 
which authentrfication of a subdirectory is carried 
out by applying a hashing algorithm to at least tiie 

10 file authentification value, the resulting hash value 
being stored as the sutxjirectory authentrfication 
value in the referring root directory. 

6. A method as claimed in any preceding claim in 
75 which autiientif ication of a plurality of subcfirectories 

is carried out by applying a hashing algorithm to an 
accumulation of file authentification values from a 
plurality of sulxii rectories to generate a single hash 
value. 

20 

7. A method as claimed in any preceding claim in 
which at least some of the data stored in the. root 
directory is acted upon by a secret key of an 
encryption algorithm and the resulting encrypted 

25 value stored in the root directory. 

8. A method as claimed in claim 7. in which the 
encrypted data con-esponds to a digital signature 
generated using a private key of an encryption 

30 algorithm, tiie signature being verifiable by use of a 
corresponding public key. 

9. A method as clainned in any preceding claim in 
which a referred module includes an encrypted 

35 value generated by a secret key. an authentrfication 
value for this module being calculated based on the 
results of an autiientification algorithm on the 
encrypted value and stored in the referring module. 

40 1 0. A method as claimed in daim 9 in which a signature 
value for the refen-ed module is generated by an 
encryption algorithm, the signature value being 
acted upon by a hashing algorithm to generate ttie 
authentification value. 

45 

11. A method as claimed in claim 9 or 10 in which the 
referred module is a second root directory module. 

12. A method as claimed in any preceding claim in 
so which the data modules con-espond to a set of data 

files, the data files being ttiereafter encapsulated in 
data packets to form a transport stream. 

13. A method as claimed in claim 12 in which the data 
55 modules correspond to data objects formatted 

according to the DSh/ICC standard. 

14. A method as daimed in claim 12 or 13 in which the 
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data fil^ are encapsulated in data packets con- 
forming to the MPEG standard. 

« and second 

sron. charactensed in that one of the first set of 
modules includes a signature generated by a secret 

^IT^ ^i"^ authentified by an authentificSion 
a^gorrthm and the aulhentification value beino 
stored in a module in the second set of modules 
that refer to that first module. 

en^2IS ^l'^^"'^ '" Claim 15 in which the 
oeSSS h '^^P^^ to a digital signature 
generated by a secret key acting upon at least 
some of the data in that module. 

Jirdl^l^l"""^ 15 and 16 in which 

SSiTk ^ ^''^"^ '° « =^ °' -^ata files. 

r/d?* !! ^'"^ encapsulated in data 

packets to form a transport stream. 

18. A method of authentiflcation of data sent in a digital 
transmission characterised in that data is or^^ 
°^ a'^antification being «r- 
r.«l out between files and prior to encapsulation of 
the files m a series of packets in a transport strearn. 

T^- .Vt'^^ transmission system corresponds 
to a digital television system. «*~na5 
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Fig.4. 
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